Method and system of applying policy on screened files

ABSTRACT

Described is a mechanism comprising a data screening filter and user mode service that applies (enforces) policies regarding allowing or blocking file content of a directory, based on matching the filename against patterns associated with that directory. An administrator configures a screening policy, such as the types of files to allow in a particular directory and the types of files to block. File groups of member patterns and non-member exclusion patterns are defined and selectively collected in directory screening objects (DSOs). A directory screening object (DSO) is associated with a directory. When an I/O create request specifying a filename and a target directory is received, the filename is evaluated against the member/non-member patterns in the file groups referenced by the DSO for that directory to make for an allow or block policy decision. If not matched, DSOs on parent directories are evaluated upwards seeking a policy decision.

FIELD OF THE INVENTION

The invention relates generally to computer systems, and moreparticularly to computer files and storage.

BACKGROUND

Computer system administrators want to control the content that isstored on the computer systems (e.g., individual user's managedcomputers and network server shares) for which they are responsible.There are many reasons for needing control, including blocking certaintypes of files from being saved, preventing wasted space, organizingfiles on particular storage volumes for convenience and possiblysecurity, and in general just knowing what is and what is not present ona file system volume.

For example, an enterprise may not want its employees to store largevideo files on shares on an enterprise server, as this consumes space.Similarly, an enterprise may also want to prevent storage of contentsuch as music files that potentially make the enterprise liable forcopyright infringement.

An enterprise or group therein may want only certain types of files on anetwork share, such as shared files used in day-to-day work operations.With respect to knowing what is on a storage volume, an administratormay want to know when certain files are added to the storage volume,such as to know when a user has installed (or even attempted to install)an executable program on a managed computer that is supposed to have acarefully-controlled set of executables.

At present, there is no known way to control content storage in suchvarious ways, other than by manually inspecting file storage, orapplying a utility program to do so, sometime after those files havealready been stored and possibly used. While a utility could scan thefile system and remove files deemed undesirable or move files where theydo belong, doing so is time-consuming as well as after the fact. Suchpost-storage approaches also would lead to situations in whichincorrectly named files or files inadvertently stored on the wrong fileshare suddenly disappear without the user knowing what happened.

What is needed is a mechanism for administrators to control the contenton computer systems and storage volumes according to a policy, in whichthe policy may be applied in conjunction with the initial request tocreate a file (including copying the file from elsewhere) or rename afile on a storage volume. Such a mechanism should be sufficientlyflexible for administrators to handle the many possible situations thatmay arise in a given computing environment.

SUMMARY OF THE INVENTION

Briefly, the present invention is directed towards a system and methodby which the I/O requests issued by programs are screened to determinewhether to allow certain file system-related operations (e.g., filecreates) with respect to individual directories in a directoryhierarchy. For example, based on a relationship between a filenameprovided with a create request and pre-established pattern data, certainfiles or types of files trigger policy, which may include blocking thatfile from being created (or renamed to a blocked name) on the targetdirectory for which file creation has been requested. Instead of or inaddition to blocking, additional policy such as writing an audit logrecord, or sending an e-mail, may be applied.

In one implementation, the administrator uses file groups containingpattern data (sets of file namespace patterns which may includewildcards) arranged into member patterns and/or non-member patterns (alist of exceptions to member patterns). A file group is a logicalclassification of files based on certain properties, such as the nameand extension of the file. For a given filename, membership of a file ina file group is determined by establishing whether the filename matchesany of the non-member patterns; if so then the file is not a member ofthe group. If not, the filename is evaluated to determine whether itmatches any of the member patterns; if so, then the file is a member ofthe group. If there is not a match with the non-member patterns ormember patterns, the file is not a member of the group. Thus, thenon-member list takes precedence over the member list, enabling anadministrator to grant file group membership to certain categories offiles yet specify exceptions to membership via the non-member patternslist.

Via pattern data arranged within file groups, an administrator appliespolicy to a directory based on whether a given file is a member of afile group or set of file groups. To tie the pattern data to adirectory, a data screen object is used as an association unit, in whichthe data screen object contains lists of one or more file groups toassociate with a directory, and thereby defines the screening policy ona directory.

A Data Screen Object is defined by a list of zero or more “allow” filegroups, and a list of zero or more “block” file groups. When a createrequest is received, the screening decision for a file with respect tothe target directory is determined by establishing whether the file(based on the filename) is a member of any of the “allow” file groupslisted in the data screen object on the directory; if so, a first policyis applied, which is typically NULL policy, wherein the requestedoperation is not considered a violation and the request is allowed toproceed.

If the file is a member of any of the “block” file groups of the datascreen object on the directory, a second policy is applied, typicallycorresponding to a violation. Thus, on the same directory, allow takesprecedence over block, so that a data screen object enables theadministrator to block certain types of files in the directory, with theallow overriding the blocking action for certain groups of files.

If neither a member of an allow file group or a block file group, theparent of the directory is checked for a data screen object to look forpolicy to apply. If no policy is found, the mechanism walks up the treeto the next parent directory and so forth, looking for a data screenobject that has an allow or block match, until a policy is applied orthere is no parent. If no parent, the allow policy (typically no action,thereby allowing the request to proceed) is applied. Thus, screeningpolicies on sub-directories take precedence over parent directories inan upward direction, whereby an administrator set a screening policy ona directory and also set one on a subdirectory to exclude thesub-directory from some screening policy effective on its parent. Thescreening for a subdirectory may be more restrictive.

In one implementation, the screening mechanism comprises a kernel modedata screen filter and a user-mode storage resource management service.As computer programs (e.g., user mode programs and kernel modecomponents above the data screen filter) make file system-directedcreate requests via API calls, corresponding I/O requests reach the datascreen filter. The data screen filter then processes the request usingdata screen objects with their references to file groups as describedabove to match filenames against patterns for the directory, and ifnecessary for parent directories, until a policy application isdetermined. In this manner, file creates and other file I/O requests canbe blocked by policy before occurring, providing dynamic screening forcontent on a per-directory basis.

Other advantages will become apparent from the following detaileddescription when taken in conjunction with the drawings, in which:

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a block diagram generally representing a computing environmentinto which the present invention may be incorporated;

FIG. 2 is a flow diagram generally representing logic for determiningwhether a given filename is a member or non-member of a file group, inaccordance with various aspects of the present invention;

FIG. 3 is a representation for visualizing the concepts of a file grouphaving a member set and a non-member set in a file system namespace, inaccordance with various aspects of the present invention;

FIG. 4 is a block diagram including a filter manager architecture andcomponents for applying per-directory policy based on a filename versuspattern data, in accordance with various aspects of the presentinvention;

FIGS. 5 and 6 comprise representations of directory structures, eachstructure having directory nodes with associated data screen objectsthat relate to file group patterns that are used for determining whetherto apply policy in accordance with various aspects of the presentinvention; and

FIG. 7 is a flow diagram generally representing logic for handling arequest to create a file on a directory by determining whether to applypolicy, in accordance with various aspects of the present invention.

DETAILED DESCRIPTION Exemplary Operating Environment

FIG. 1 illustrates an example of a suitable computing system environment100 on which the invention may be implemented. The computing systemenvironment 100 is only one example of a suitable computing environmentand is not intended to suggest any limitation as to the scope of use orfunctionality of the invention. Neither should the computing environment100 be interpreted as having any dependency or requirement relating toany one or combination of components illustrated in the exemplaryoperating environment 100.

The invention is operational with numerous other general purpose orspecial purpose computing system environments or configurations.Examples of well known computing systems, environments, and/orconfigurations that may be suitable for use with the invention include,but are not limited to: personal computers, server computers, hand-heldor laptop devices, tablet devices, multiprocessor systems,microprocessor-based systems, set top boxes, programmable consumerelectronics, network PCs, minicomputers, mainframe computers,distributed computing environments that include any of the above systemsor devices, and the like.

The invention may be described in the general context ofcomputer-executable instructions, such as program modules, beingexecuted by a computer. Generally, program modules include routines,programs, objects, components, data structures, and so forth, whichperform particular tasks or implement particular abstract data types.The invention may also be practiced in distributed computingenvironments where tasks are performed by remote processing devices thatare linked through a communications network. In a distributed computingenvironment, program modules may be located in local and/or remotecomputer storage media including memory storage devices.

With reference to FIG. 1, an exemplary system for implementing theinvention includes a general purpose computing device in the form of acomputer 110. Components of the computer 110 may include, but are notlimited to, a processing unit 120, a system memory 130, and a system bus121 that couples various system components including the system memoryto the processing unit 120. The system bus 121 may be any of severaltypes of bus structures including a memory bus or memory controller, aperipheral bus, and a local bus using any of a variety of busarchitectures. By way of example, and not limitation, such architecturesinclude Industry Standard Architecture (ISA) bus, Micro ChannelArchitecture (MCA) bus, Enhanced ISA (EISA) bus, Video ElectronicsStandards Association (VESA) local bus, and Peripheral ComponentInterconnect (PCI) bus also known as Mezzanine bus.

The computer 110 typically includes a variety of computer-readablemedia. Computer-readable media can be any available media that can beaccessed by the computer 110 and includes both volatile and nonvolatilemedia, and removable and non-removable media. By way of example, and notlimitation, computer-readable media may comprise computer storage mediaand communication media. Computer storage media includes volatile andnonvolatile, removable and non-removable media implemented in any methodor technology for storage of information such as computer-readableinstructions, data structures, program modules or other data. Computerstorage media includes, but is not limited to, RAM, ROM, EEPROM, flashmemory or other memory technology, CD-ROM, digital versatile disks (DVD)or other optical disk storage, magnetic cassettes, magnetic tape,magnetic disk storage or other magnetic storage devices, or any othermedium which can be used to store the desired information and which canaccessed by the computer 110. Communication media typically embodiescomputer-readable instructions, data structures, program modules orother data in a modulated data signal such as a carrier wave or othertransport mechanism and includes any information delivery media. Theterm “modulated data signal” means a signal that has one or more of itscharacteristics set or changed in such a manner as to encode informationin the signal. By way of example, and not limitation, communicationmedia includes wired media such as a wired network or direct-wiredconnection, and wireless media such as acoustic, RF, infrared and otherwireless media. Combinations of the any of the above should also beincluded within the scope of computer-readable media.

The system memory 130 includes computer storage media in the form ofvolatile and/or nonvolatile memory such as read only memory (ROM) 131and random access memory (RAM) 132. A basic input/output system 133(BIOS), containing the basic routines that help to transfer informationbetween elements within computer 110, such as during start-up, istypically stored in ROM 131. RAM 132 typically contains data and/orprogram modules that are immediately accessible to and/or presentlybeing operated on by processing unit 120. By way of example, and notlimitation, FIG. 1 illustrates operating system 134, applicationprograms 135, other program modules 136 and program data 137.

The computer 110 may also include other removable/non-removable,volatile/nonvolatile computer storage media. By way of example only,FIG. 1 illustrates a hard disk drive 141 that reads from or writes tonon-removable, nonvolatile magnetic media, a magnetic disk drive 151that reads from or writes to a removable, nonvolatile magnetic disk 152,and an optical disk drive 155 that reads from or writes to a removable,nonvolatile optical disk 156 such as a CD ROM or other optical media.Other removable/non-removable, volatile/nonvolatile computer storagemedia that can be used in the exemplary operating environment include,but are not limited to, magnetic tape cassettes, flash memory cards,digital versatile disks, digital video tape, solid state RAM, solidstate ROM, and the like. The hard disk drive 141 is typically connectedto the system bus 121 through a non-removable memory interface such asinterface 140, and magnetic disk drive 151 and optical disk drive 155are typically connected to the system bus 121 by a removable memoryinterface, such as interface 150.

The drives and their associated computer storage media, described aboveand illustrated in FIG. 1, provide storage of computer-readableinstructions, data structures, program modules and other data for thecomputer 110. In FIG. 1, for example, hard disk drive 141 is illustratedas storing operating system 144, application programs 145, other programmodules 146 and program data 147. Note that these components can eitherbe the same as or different from operating system 134, applicationprograms 135, other program modules 136, and program data 137. Operatingsystem 144, application programs 145, other program modules 146, andprogram data 147 are given different numbers herein to illustrate that,at a minimum, they are different copies. A user may enter commands andinformation into the computer 110 through input devices such as atablet, or electronic digitizer, 164, a microphone 163, a keyboard 162and pointing device 161, commonly referred to as mouse, trackball ortouch pad. Other input devices not shown in FIG. 1 may include ajoystick, game pad, satellite dish, scanner, or the like. These andother input devices are often connected to the processing unit 120through a user input interface 160 that is coupled to the system bus,but may be connected by other interface and bus structures, such as aparallel port, game port or a universal serial bus (USB). A monitor 191or other type of display device is also connected to the system bus 121via an interface, such as a video interface 190. The monitor 191 mayalso be integrated with a touch-screen panel or the like. Note that themonitor and/or touch screen panel can be physically coupled to a housingin which the computing device 110 is incorporated, such as in atablet-type personal computer. In addition, computers such as thecomputing device 110 may also include other peripheral output devicessuch as speakers 195 and printer 196, which may be connected through anoutput peripheral interface 194 or the like.

The computer 110 may operate in a networked environment using logicalconnections to one or more remote computers, such as a remote computer180. The remote computer 180 may be a personal computer, a server, arouter, a network PC, a peer device or other common network node, andtypically includes many or all of the elements described above relativeto the computer 110, although only a memory storage device 181 has beenillustrated in FIG. 1. The logical connections depicted in FIG. 1include a local area network (LAN) 171 and a wide area network (WAN)173, but may also include other networks. Such networking environmentsare commonplace in offices, enterprise-wide computer networks, intranetsand the Internet.

When used in a LAN networking environment, the computer 110 is connectedto the LAN 171 through a network interface or adapter 170. When used ina WAN networking environment, the computer 110 typically includes amodem 172 or other means for establishing communications over the WAN173, such as the Internet. The modem 172, which may be internal orexternal, may be connected to the system bus 121 via the user inputinterface 160 or other appropriate mechanism. In a networkedenvironment, program modules depicted relative to the computer 110, orportions thereof, may be stored in the remote memory storage device. Byway of example, and not limitation, FIG. 1 illustrates remoteapplication programs 185 as residing on memory device 181. It will beappreciated that the network connections shown are exemplary and othermeans of establishing a communications link between the computers may beused.

Data Screening

The present invention is generally directed towards a system and methodby which the I/O requests issued by computer programs are screened todetermine whether to allow certain file system-related operations (e.g.,file creates) with respect to individual directories in a directoryhierarchy. For example, based on a relationship between a filenameprovided in association with the create request and pre-establishedpattern data, certain files or types of files trigger policy, which mayinclude blocking that file from being created (or renamed to a blockedname) on the target directory for which file creation has beenrequested. As will be understood, this is accomplished by code thatanalyzes each such request dynamically, as it occurs, so that amongother things, if policy is to block a certain file's creation, theblocked file is never created, even temporarily, and the user can knowimmediately that the file was not successfully created, as well as thereason.

Thus, the present invention is primarily directed towards evaluating afile system operation (e.g., a file create) to determine whether basedon the full path information associated with the file system request,(e.g., volume, directory path and filename or UNC path), policy isapplied (e.g., blocking creation of that file in the directory on whichcreation is requested). However, as will be understood, the presentinvention is not limited to blocking file creation or renames, but canapply other policy in addition to blocking or instead of blocking. Forexample, the creation may be allowed to occur, but as determined bypolicy, some other action may be taken, e.g., the create event may belogged such as to an audit file, a message may be sent (e.g., to thesystem administrator), and so forth. Policy that blocks file creationalso may cause additional policy to be applied. Further, the presentinvention is not limited to applying policy only on create or renamerequests, but can apply policy on other types of file system requests;different policies may apply to different types of requests, anddifferent policies may apply depending on the evaluation result. Thus,although the examples herein are primarily directed towards applyingpolicy or not with respect to file creation/renaming request based onevaluation of a filename and the directory information accompanying therequest, it is understood that these are only examples.

As will be also understood, numerous ways to implement the presentinvention are feasible, and only some of the alternatives are describedherein. For example, the present invention is primarily described belowwith reference to I/O request packets (IRPs) that pass through a set offilter drivers, in which the IRP passing may be controlled by a filtermanager via pre-callbacks and post-callbacks. However, the presentinvention may alternatively be implemented in an arrangement in whichthe passing may be through a stack of filter drivers, sequentially fromone filter driver to the next, and/or in the file system itself.Moreover, the program having its I/Os evaluated may be writing to one ormore local file system volumes and/or to one or more network servers,and each may have different directory structures and associatedpolicy-related data. Notwithstanding, other types of filter driverarrangements, I/O passing and/or storage options are feasible. Forexample, the present invention may be configured to work in anarchitecture where requests are not passed as IRPs, but in some otherformat. As such, the present invention is not limited to any particularexamples used herein, but rather may be used various ways that providebenefits and advantages in computing in general.

In order to configure the I/O subsystem to determine what policy, ifany, should be applied, the administrator needs a way to distinguishvarious types of filenames from one another. Although the administratorcould individually list each filename for which policy would be applied,this would be time-consuming and highly inefficient, as frequently it istypes of files, as denoted by their file extension, to which anadministrator wants policy applied. To this end, a data screen pattern,or simply a pattern for short, defines a set of filenames (pattern data)that can be compared against a requested filename. In oneimplementation, pattern data may include filenames specified in the formof a wildcard (such as “*” or “?”), e.g., *.exe will identify any filewith an .exe extension, the well-known extension for executable files.Note that *.ex? is a pattern which *.exe executable files match, as dofiles of type *.exa, *.exb, *.ex2 and the like, essentially representinga three-character filename extension that substitutes any thirdalphanumeric character (or other suitable character) that is a validcharacter for filenames for the “?” wildcard.

Although the availability to use wildcards in pattern data is efficient,wildcards are not required in the present invention, as otheralternatives including individual filename listings and/or ranges offiles/extensions (such as file extensions mp0 through mp9 inclusive) maybe used to specify files. Notwithstanding, wildcards are describedherein as one suitable mechanism for identifying files, because of theirefficiency in allowing administrators to identify entire types of filesat once, and because the usage and handling of wildcards is a wellestablished and understood part of file system technology. Further,wildcard use is optional in that even with wildcard availability, anentire filename and/or extension without wildcards may be used instead,meaning that listing individual files is still an option. Note thatwhile the present invention is primarily described with reference tofile types as recognized by their extensions, any suitable part or allof a filename may correspond to a pattern. Thus, with wildcards, severalthousand files that range from a2.text to a999999.txt may be simplyrepresented in pattern data by a*.txt, demonstrating another advantageof wildcards.

Because wildcards can encompass more files and file type than desired,one implementation uses the concept of maintaining various sets ofpattern data in file groups, wherein a file group is a logicalclassification of files based on certain properties, e.g., the name andextension of the file. Each file group contains a list of zero or moremember patterns corresponding to filenames to include as part of thegroup, and/or a list a zero or more non-members patterns, comprising alist of exceptions to the member patterns. As described below,non-members override and thus exclude filenames that may be otherwiseidentified by a pattern in the member group.

By way of example, consider a file group of music-type files defined bymember pattern(s) of *.mp* and non-member patterns of *.mpp and *.mpv.Any music files, such as one named mysong.mp3, is considered a member ofthe group, whereas a project file named myproject.mpp is considered anon-member, as would any files that do not match the member pattern atall, e.g., myspreadsh.xls. This result occurs because the default isthat a file is a non-member unless listed as a member, with an exceptionnon-member list that takes precedence over the member list. This allowsan administrator to grant file group membership to one or more certaincategories of files, and then specify exceptions to membership grantedby the member patterns list, with completely unrelated files (of course)not being considered as members. Note that it is essentially equivalent,although somewhat less intuitive, to do this in reverse, e.g., startwith every file being a member unless specified as a non-member, andthen specify exceptions that make files members within the non-memberset.

FIG. 2 shows example logic for determining whether a given filename iswithin a given file group or set of file groups. As can be seen, step202 first looks for non-member exclusions. If the filename fits into anynon-member pattern, (there may be from zero to any practical number ofnon-member patterns), the file is excluded from that group, and anindication provided (e.g., FALSE) as appropriate via step 206. Note thatthe exclusion is immediate, regardless of whether any non-memberpatterns remain to be evaluated and regardless of the member patterns,because matching any one non-member pattern is sufficient to exclude thefile from the file group, and exclusions override inclusions in a membergroup.

Returning to step 204, if no match is found using the non-memberpatterns (including if there are zero non-member patterns), step 202instead branches to step 204, where an evaluation of the filename isperformed against the member patterns in the file group or set of filegroups. If the filename fits into any member pattern, (there may be fromzero to any practical number of member patterns), the file isimmediately considered to be a member of that group regardless ofwhether any member patterns remain to be evaluated, (since the filegroup is essentially a union of patterns), and an indication (e.g.,TRUE) provided as appropriate via step 204.

If step 204 cannot locate a matching member pattern, (which includeswhen the member set is a NULL set), the file is not in the group, andthus step 204 branches to step 206 where a “not-in-group” indication isprovided (e.g., FALSE) as appropriate.

The patterns in a file group or set of file groups may be arranged inany order, such as sorted for efficiency, e.g., patterns believed (ormeasured in some way) to correspond to more common types of filenamesmay be arranged to be evaluated first. The file groups can also beordered within the data screening object, such as for similar purposes.Note that file groups may be used for other applications that operatebased on file classification.

FIG. 3 is a representation (not to any scale) to help visualize vianamespaces the members and non-members in a file group. In general, allfiles (*.*) are not members of a given file group unless listed in thefile group. A file group, such as the music-related file group that hadmp* as a pattern in its member list, defines a set of files within thepossible file namespace. This is represented in FIG. 3 by the smallernon-shaded area (the member list namespace) within the large shaded area(the total possible namespace). Within the member area are thenon-member exclusions, comprising the namespaces represented by thesmaller shaded areas. As is readily apparent from FIG. 3, the only filesthat remain in the member file group namespace are those in thenon-shaded area. As seen in FIG. 2, described above, if a file fallsinto the small shaded areas, it is immediately not in the group; if notwithin such an exception area, the file is then tested for whether itfalls in the remaining non-shaded area; only if so is the file withinthe file group.

Via pattern data arranged within file groups, an administrator can nowapply policy based on whether a given file is a member of a file groupor set of file groups. To tie pattern data to a directory, a data screenobject is used as an association unit, in which the data screen objectcontains lists of one or more file groups to associate with a directory,and thereby defines the screening policy on a directory. In oneimplementation, each directory may have only one data screen object(DSO), but in alternative implementations, a directory may have multipledata screen objects, which may all apply or selectively apply, e.g.,possibly different ones for different categories of users/usergroups,different ones for different types of evaluations (e.g., a file createrequest has one and a file read request has another) and so on. Forpurposes of simplicity, an implementation having only one data screenobject per directory will be described herein.

As described below, a data screen object is defined by a list of zero ormore “allow” file groups and a list of zero or more “block” file groups.Note that the terms “block” and “allow” comes from the likelihood thatthe most typical policy decision will be to block or allow filecreation, although as described below actual blocking of a file createis not required when applying “blocking” policy.

In addition to the file group information, it is also feasible to putdifferent policy information in each data screen object and thereby havediffering policies apply to different directories depending on itsassociated data screen object, however for purposes of simplicity, thepolicy will be the same for all directories. Further, note that it isfeasible to have the data screening objects be set up with the memberand non-member pattern lists directly, rather than indirectly viareferences to the file groups that contain those lists, however the useof file groups provides administrators with flexibility and ease of use,as well as the include with exclude override. Note that after setup,when needed in actual operation, the data screen object in-memorystructure may indeed contain the (e.g., unioned) member and non-memberpattern lists directly, pre-processed into the block and allow lists,rather than containing references to file groups, such as for purposesof efficiency. For purposes of explanation herein, the present inventionwill be described with data screen objects that contain reference(s) tofile group(s).

In operation, the data screen objects and file groups are used todetermine whether to apply policy when a relevant file-system relatedrequest is received, such as a request to create a given file on a givendirectory. As is known, such a request contains information (e.g., afull path) from which the desired directory and desired file areidentifiable. FIG. 4 shows an architecture in which a filter driverevaluates such a request in accordance with various aspects of thepresent invention. In general, a filter driver (or simply “filter”) issoftware code that is able to inspect and possibly modify data sent toor received from a file system. For example, an antivirus filter drivermay look for virus signatures, a quota filter driver may watch a user'sdisk space consumption, an encryption filter driver may encrypt data onits way to the file system and decrypt it on the way back, and so forth.

As represented in FIG. 4, one exemplary arrangement 400 of components ofa system is provided into which the present invention may beincorporated via a filter driver. The components include one or moreuser-mode (e.g., application or shell) programs 402, a set ofapplication programming interfaces (APIs) 404, an input/output (I/O)manager 406, a filter manger 408, a file system 410, storage volume 412,and filters 420-422. As is generally known with filter drivers, theremay be any number (including zero) of higher-level filters 420 and/orlower-level filters 422 installed relative to another driver in anygiven implementation. Note that the present invention may work withmultiple file systems and/or multiple storage volumes, as long as thedirectory structure and data screening object associations are known foreach volume, however for purpose of simplicity, FIG. 4 shows one filesystem 410 and one storage volume 424, which may be local or remote.

In accordance with an aspect of the present invention, two componentsshown in FIG. 4 are directed towards evaluating file system createrequests received as I/Os to determine whether policy is to be appliedto those requests. These components include a user-mode storage resourcemanagement service 430 and one of the filter drivers, namely the datascreen filter 421. For various purposes described below, the user-modestorage resource management service 430 has an associated data store 432containing file group (FG) information and data screen object (DSO)information, (although the data screen filter 421 may persist thisinformation instead). A user interface (not shown) or the like allowsadministrators to maintain the data store 432 as necessary.

As will be understood, the separation of the data screen filter 421 andstorage resource management service 430 is for convenience andefficiency in this architecture, and the division in structure and/orfunctionality between them is somewhat arbitrary except that in general,kernel-mode components are generally written to be highly efficient andas straightforward as possible to avoid potential errors. Thus, althoughit is understood that essentially all of the present invention'sscreening operations may be implemented in the filter driver component421, having some of the work performed in the user-mode component 430provides certain advantages and benefits, and thus is used inenvironments where some communication channel exists between theuser-mode component 430 and the kernel-mode component 421.Notwithstanding, it is feasible to implement a filter driver that isinstalled and configured, such as following system boot or on demand,that obtains the data needed to screen I/Os and apply policy untilhalted in some manner.

User-mode computer programs 402 often make file system-directed createrequests via API calls through the API set 404 to the I/O manager 406,such as when creating a new file or copying or moving an existing filefrom another storage location. In general, the I/O manager 406 maydetermine what I/O request or requests should be issued to fulfill eachprogram request, and sends the corresponding request or requests to thefilter manager 408. In the example implementation described herein, theI/O manager sends requests in the form of an I/O request packet, or IRP.The I/O manager 404 also returns status codes and/or data to theuser-mode programs 402 in response to the API calls. Note that kernelmode components can also make file-system directed I/O requests, andthus the data screen filter 421 may receive IRPs initiated by kernelmode components that are above the data screen filter, as well asreceive IRPs corresponding to file-system directed requests initiated byuser-mode programs.

In one implementation, described in U.S. patent application Ser. No.10/315,384, filter drivers may register (e.g., during an initializationprocedure) with a registration mechanism with the filter manager 408.For efficiency, each filter driver typically will only register for filesystem requests in which it may be interested in processing. To thisend, as part of registration, each filter driver notifies the filtermanager 408 of the types of I/O requests in which it is interested(e.g., create, read, write, close, rename, and so forth). For example,an encryption filter driver may register for read and write I/Os, butnot for others wherein data does not need to be encrypted or decrypted.Similarly, a quota filter driver may be interested only in objectcreates and object writes.

In the current example described herein in which the filter driver 421wants to screen newly created or renamed files, the data screeningfilter driver registers for any I/O request that creates or renames afile on a directory. Note that the opening of an existing file may causepolicy to be applied, however if the policy blocked the opening of thefile, in one implementation the file could not be deleted if the openwas blocked because an open is necessary to delete the file, and thusopens are not blocked. Notwithstanding, with the present invention,policy may be applied per directory for files with respect to any typeof file system-directed request, including opens, reads, writes,deletes, closes and so forth.

In addition to specifying the types of I/O requests in which it isinterested, a filter driver may further specify whether the filterdriver should be notified for pre-callbacks and post callbacks for eachof the types of I/O. A pre-callback is called as data associated with anI/O request propagates from the I/O manager 406 towards the file system410, while a post-callback is called during the completion of the I/Orequest as data associated with the I/O request propagates from the filesystem 410 towards the I/O manager 406. During pre-callback, a filterdriver can opt out of receiving a post-callback for a particular IRPeven if it is generally registered for those types of IRPs. In general,the filter manager 408 receives IRPs from the I/O manager 406 andsequentially passes data associated with that IRP to each filter driverregistered for that type of request, in an order that generally dependson whether and how the filter driver modifies the data or not, e.g., anantivirus filter driver should come before an encryption filter driverfor data on its way to the file system so that the antivirus filterdriver can see the data in its unencrypted form.

As described below, for efficient operation, the filter driver 421 maystore a needed amount of data in memory so that it does not need tocommunicate with user mode code to retrieve regularly-needed data. Inone implementation, the data maintained by the filter driver isprimarily provided to it by the user-mode storage resource managementservice 430. To this end, the user-mode storage resource managementservice 430 and the corresponding filter driver 421 have a communicationchannel, e.g., the filter manager 408 recognizes and appropriatelyroutes such communications, which are thus essentially private. Thiscommunication channel is represented in FIG. 4 by the relatively-widegray arrow; note that this channel may be protected such thatadministrator-level privileges are required to communicate over it.

In the present example in which the filter driver 421 is evaluatingcreate requests on a per-directory basis, the filter driver obtains thedata screening objects 440 and file groups 442, as well as arepresentation (e.g., a set of nodes) of the current volume's directorystructure 444, which also contains information indicating whichdirectories are associated with which data screening objects; a givendirectory need not have any association. The data screen filter 421 thenhas knowledge of the data screen object for each directory (e.g., node)of the directory structure, and the data screen objects in turn tie thefile groups to the directory, whereby that the filter 421 can begin itsfiltering operation. Miscellaneous working data 446 is also shown, suchas for storing some policy-related data (e.g., actually block on apolicy violation or not). In keeping with the present invention, withthis information, the data screen filter 421 may evaluate file-systemrequests (such as create requests) against membership information, on aper-directory basis, and thereby produce a policy-related result.

FIGS. 5 and 6 show example directory structures (for different volumes)with data screen objects associated with administrator-selecteddirectories, wherein as described above, the data screen objects containreferences to file groups that in turn contain the member and/ornon-member patterns. Thus, in FIG. 5, it is seen that an administratorhas set one data screen object DSO1 to be associated with a “Users”directory, and another data screen object DSO2 to be associated with aparticular user directory, U3. Different data screen objects (e.g., DSO1and DSO2) can both contain references to a common file group (e.g.,MusicFG), and although not readily apparent from FIG. 5, anadministrator can reuse data screen objects among different directories.In FIG. 6, it is seen that that an administrator has set a data screenobject DSO4 to be associated with a “Shared Files” directory, anotherdata screen object DSO3 to be associated with a particular directory,Spreadsheets, and another data screen object DSO11 to be associated witha particular directory, WordDocs. The evaluation of a filename using thedata screen objects is described below with reference to FIG. 7.

Returning to FIG. 4, in a typical configuration, the filter driver 421may be configured to block file creation on a particular directory for agiven file, which it can do by stopping the I/O request (e.g., duringthe pre-callback phase), and may instruct the filter manager 408 toreport a status code (e.g., failure) for the I/O request. As describedbelow, the filter driver 421 will also notify the user-mode storageresource management service 430 anytime policy is deemed to apply, sothat the user-mode storage resource management service 430 may apply thepolicy (or additional policy). The notification may includeidentification as to which data screening object, directory and/orfilename caused the policy violation, so that the user mode service 430has this knowledge. Note that for efficiency, rather than waiting forinstructions from the user mode code 430, the data screen filter 421 maybe instructed in advance whether to block file creation when a file isfound to be a member of a blocked file group (as well as notify thestorage resource management service 430), or allow the file creation andonly notify. As described above, such policy data may be provided duringinitialization, and is typically for all directories but may be perdirectory if provided (e.g., within the directory structure 444), or perdata screen object (e.g., if provided within the data screen object).

To determine whether to apply policy when a file create request isreceived (the full path is essentially identifiable via the request),FIG. 7 shows example logic used by the data screen filter 421, beginningat step 700 where the target directory in which the file create is beingrequested (typically but not necessarily a subdirectory in the directorytree) is located and set as the current directory.

Step 702 evaluates whether this current directory has a data screeningobject associated with it, e.g., found via the directory structure 444.If not, then this directory is not directly subject to policy, howeverit may inherit policy from a higher parent directory, and thus step 702branches to step 712 to essentially walk up the directory tree untilsome policy is found that either allows the file or blocks the file, orthe root is reached without any policy to apply.

If instead at step 702 there is a data screening object, then its filegroup or file groups need to be evaluated against the filename todetermine whether policy is to be applied to this particular file.First, the allow file groups are tested, generally using the logic ofFIG. 2 to determine if there is membership in an allow file group,because if specifically allowed by being a member of any allow filegroup(s) listed in the data screen object associated with the currentdirectory, the requested operation is deemed to not be a violation ofpolicy. In this event, step 704 branches to step 716 where the allow“policy” is applied, (in this example, there is no allow policy otherthan to do nothing, which is equivalent to a policy of NULL), wherebythe file is allowed to be created on the target directory as originallyrequested. Note that in alternative implementations, there may be anallow policy that actually performs some action at step 716, whether inthe driver or by a notification to the user mode service 420; forexample, the file creation may be still conditional on some otherpolicy, e.g., allow the create if the file size is less than 10 MB,otherwise block creation. Further, note that creation may be preventedfor another reason, such as prevented in another driver or the filesystem, and thus “allow” as used in this context means allow the requestto proceed further.

If instead at step 704 the file name is not a member of an allow group(or there are no allow groups, which essentially means the same thing),step 704 branches to step 706 to evaluate the filename against the“block” file group or groups listed in the data screen object. If atstep 706 the file is a member of any block file group(s) of the datascreen object for the current directory, the operation is a violation ofpolicy, and step 706 branches to step 708 where any blocking policy thatthe driver 421 can apply is applied (e.g., the file create is blocked),followed by step 710 where the user mode service is notified of thepolicy violation.

In the event that the filename was not a member of either the allow filegroup(s) or block file group(s), then the parent directory, if thecurrent directory is not already the root, needs to be evaluated. Thisis because policy screening decisions associated with a directory applyto that directory as well as any subdirectories, unless overridden bypolicy at the subdirectory. Steps 712 and 714 are repeated as necessaryto walk up the tree towards the root looking for a data screening objectthat will result in a decision, until one is found or there is no parentbecause the current directory is already at the root directory.

As can be understood from FIG. 7, by starting at the target directorythat the file request has specified and walking up as necessary,screening policies on lower directories take precedence over theirparent directories. This allows an administrator to set a screeningpolicy on a directory, and also set one on a subdirectory, while givingthe subdirectory policy precedence. This is generally because asubdirectory is frequently a narrower subset of a parent, and thus mayrequire an exception to a general rule for a parent. In other words,this semantic allows an administrator to exclude a subdirectory fromsome screening policy effective on its parent. It also allows theadministrator to set up more restrictive screening on a subdirectory.

Moreover, by evaluating for an allow result before a block result on thesame directory, membership in an allow file group takes precedence overmembership in a block file group. This is because the default behaviorin a directory is to allow all files, whereas a data screen objectallows the administrator to block certain types of files in thedirectory. Thus “allow” may be used to override the blocking action forcertain groups of files. Note that again, it would be largely equivalentto do this in reverse.

FIG. 5 shows how allowing and blocking works in an example directory. InFIG. 5, the administrator has essentially set up the directory and datascreen objects so that music file group files and picture file groupfiles are blocked from users, unless there is an exception set. This isaccomplished by setting DSO1 up with two block file groups, one formusic file membership (e.g., *.mp3) and one for picture file groupmembership (e.g., *.jpg or *.bmp). These lists have been kept small forpurposes of this example, however other music files and picture filesmay be listed in a given group, and moreover, a larger file group may bedefined that contains both pictures and music files in a single memberlist. Note that administrators may be provided with sets of data screenobjects and/or file groups in advance for common types of issues,whereby an administrator need not start from scratch.

As can be seen by following the logic of FIG. 7 and FIG. 2, a file namedX.mp3 will violate policy (e.g., be blocked) if an attempt is made tocreate the file in the U2 directory. This is because while the U2directory does not have an associated data screen object, a higherparent (Users) does, and a *.mp3 file is a member of the music filegroup MusicFG, which is blocked by the block list in the directoryscreen object DSO1. However, X.mpp does not violate policy, because itis not a member of the music file group MusicFG due to the fileextension listed as a non-member.

A different user, corresponding to the U3 directory, will get differentresults with respect to music files. For example consider a user thatneeds to work with music files as part of his or her job; in such asituation the administrator will make an exception. To this end, theadministrator sets a data screen object DSO2 which has the music filegroup MusicFG on its allow list. Because directly allowed, X.mp3 willnot have blocking policy applied. However, there is no such exceptionfor pictures, and thus an attempt to create Y.jpg in the same directorywill fail because of DSO1, which also lists the picture file groupPictureFG in its block list. Thus, as can be seen from FIG. 5,administrators have the ability to easily apply policy to select filetypes (or even individual files) on a per directory basis based on filegroup memberships, with the policy applied down the directory tree;allow exceptions can be made as desired.

FIG. 6 shows another example way in which the highly-flexible mechanismsof the present invention produce a desirable result. In FIG. 6, theadministrator wants to restrict a directory named Shared Files to havingonly certain types of files in directories under it, namely wordprocessing files (*.doc) and spreadsheet files (*.xls, *.123 andpossibly others not shown as indicated by the ellipsis). In thisexample, such files also need to be created in their respectivedirectories.

To accomplish this, the administrator simply blocks all files on theShared Files directory via the data screening object DSO4, and thenmakes exceptions for its subdirectories via DSO3 and DSO11, as should bereadily apparent in FIG. 6. Because files are evaluated for policyviolations walking up the tree, document file creation requests with theproper filename made to the proper corresponding directory do notviolate policy, while all others do.

It should be noted that if only creation and renaming is prevented,pre-existing files will still exist and be opened on a directory. Thesecan be allowed to stay or be cleaned up in some other manner.

Further, with the example implementation described herein, even theadministrator is blocked from overriding the policy, unless theadministrator removes the screening object or objects that apply thepolicy. However, in an alternative arrangement, different directoryscreening objects (or none instead of one) may be selected by the filterdriver 421 based on the credentials of the requesting entity, whereby anadministrator can have different rules for different users and groups,including the administrators group. To this end, the user informationwould be used to see if there was data screening object for that user atthe current directory (at a modified step 702), and if so, to use thefile groups of that particular per-user data screening object as neededat similar steps 702 and/or 704. Note that user information is alreadyknown to the filter driver stack via the IRP, (an indeed is used inother scenarios such as by per-user quota filter drivers).

As can be seen from the foregoing detailed description, there isprovided a method and system that applies policy as specified for usermode I/O requests, such as to allow or block create file requests, basedon a directory identity and a filename. The use of data screen objectsand file groups makes it easy for administrators to apply policy toindividual directories and thus control the content of storage volumes.

While the invention is susceptible to various modifications andalternative constructions, certain illustrated embodiments thereof areshown in the drawings and have been described above in detail. It shouldbe understood, however, that there is no intention to limit theinvention to the specific forms disclosed, but on the contrary, theintention is to cover all modifications, alternative constructions, andequivalents falling within the spirit and scope of the invention.

1. In a computing environment, a system comprising: a data screenmechanism that receives an I/O request directed towards a file in atarget directory of a file system volume, the I/O request containinginformation corresponding to the filename and the target directory; aset of one or more data screening objects, each data screening objectassociated with a directory of the file system volume and havinginformation corresponding to pattern data that relates to filenames; andthe data screen mechanism determining based on the target directorywhether a data screening object applies to the I/O request, and if so,evaluating the filename corresponding to the I/O request against thepattern data to determine policy application based on a relationshipbetween the filename and the pattern data.
 2. The system of claim 1further comprising a set of at least one file group, each file groupcontaining pattern data, and wherein the information corresponding tothe pattern data in the data screening object comprises a reference toat least one file group in the set.
 3. The system of claim 2 whereineach file group includes a first field for member patterns and a secondfield for non-member patterns.
 4. The system of claim 3 wherein thefilename is a member of a group when the filename does not fit a patternin the second field and fits a pattern in the first field.
 5. The systemof claim 4 wherein the data screen mechanism determines policyapplication based on a relationship between the filename and the patterndata by determining whether the filename is a member of a group.
 6. Thesystem of claim 5 wherein the data screening object contains a firstfield for listing a first set of zero or more file groups andcorresponding to a first policy, and a second field for listing a secondset of zero or more file groups corresponding to a second policy, andwherein the data screen mechanism applies the first policy if thefilename is a member of any file group in the first field and appliesthe second policy if the filename is a member of any file group in thesecond field.
 7. The system of claim 6 wherein the first fieldcorresponds to an allow policy and the second field corresponds to ablock policy, and wherein the allow policy overrides the block policy.8. The system of claim 6 wherein the filename is neither a member of anyfile group in the first field nor a member of any file group in thesecond field, and wherein the data screen mechanism determines whether adata screening object applies to the I/O request by looking for anotherdata screening object associated with at least one parent directory ofthe target directory.
 9. The system of claim 1 wherein the data screenmechanism comprises a filter driver.
 10. The system of claim 9 furthercomprising a user mode service coupled for communication with the datascreen mechanism, the data screen mechanism configured to provide anotification to the user mode service upon at least one type of policyapplication.
 11. In a computing environment, a method comprising:associating pattern data corresponding to a set of one or morenamespaces with a directory; receiving an I/O request, the request I/Oincluding data corresponding to a filename and a target directory; anddetermining whether the filename relates to the pattern data, and if so,determining a policy to apply based on the relationship of the filenameto that pattern.
 12. The method of claim 11 wherein the pattern dataincludes at least one pattern having a wildcard.
 13. The method of claim11 wherein associating the pattern data with the directory comprisesassociating a data screen object containing information corresponding tothe pattern data with the directory.
 14. The method of claim 13 whereinthe data screen object includes a first and second data fields, with atleast one field containing information corresponding to at least some ofthe pattern data.
 15. The method of claim 14 wherein the informationcorresponding to at least some of the pattern data comprises at leastone reference to the pattern data.
 16. The method of claim 14 whereinthe first field corresponds to a first policy and the second fieldcorresponds to a second policy.
 17. The method of claim 16 wherein thefirst field corresponds to an allow policy and the second fieldcorresponds to a block policy, and wherein determining the policy toapply comprises evaluating the first field for pattern data to attemptto obtain a policy result before evaluating the second field for patterndata.
 18. The method of claim 11 wherein determining whether thefilename relates to the pattern data comprises determining whether thefilename fits any pattern data for the target directory, and if so,applying a policy.
 19. The method of claim 18 wherein determiningwhether the filename fits any pattern data for the target directorycomprises determining whether a data screen object is associated withthe target directory.
 20. The method of claim 18 wherein a data screenobject is associated with the target directory and contains a firstfield for one policy and a second field for another policy, each fieldarranged to contain information corresponding to file group data inwhich any file group contains at least some of the pattern data, andwherein determining whether the filename relates to the pattern datacomprises determining whether the filename is a member of a file group.21. The method of claim 20 wherein each file group contains a data fieldfor member patterns and a data field for non-member patterns, andwherein determining whether the filename is a member of a file groupcomprises evaluating the filename against any non-member patterns beforeevaluating the filename against any member patterns, wherein when thefilename is not a member of the group if it fits any non-member patternor does not fit any member pattern. 23-39. (canceled)